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Reconsideration and further prosecution of the above 
identified application are respectfully requested in view of the 
discussion that follows. Claims 1-40 are pending in this 
Application. Claims 1-40 have been rejected under 35 U.S.C. 
§103 (a) as being unpatentable over U.S. Patent No. 6,611,590 to 
Lu et al. ("Lu") in view of U.S. Pat. No. 7,165,112 to Battin et 
al . ("Battin") in view of U.S. Pat. No. 6,757,731 to Barnes et 
al . ("Barnes") and further in view of U.S. Pat. No. 4,682,267 to 
Childress et al . ("Childress"). Claim 1, 8, 10, 12, 16, and 31 
have been amended. After careful review of the claims and the 
cited art, it is believed that the claims are in allowable form 
and therefore a Notice of Allowance is respectfully requested. 

Claims 1-40 have been rejected as obvious over Lu, Battin, 
Barnes and Childress. Lu is directed to an Internet Interface 
Controller that merely routes calls but does not determined the 
received call type nor does it perform agent selection based upon 
call type. Claims 1, 16, and 31 have been amended to recite 
continuous scanning and reading (see e.g., para. 0044). 

The Office Action cites Col. 6, lines 22-28 and Col. 7, 
lines 4-10 of Lu as disclosing determining a type of the received 
call. However, Col. 6, lines 22-28 describes IIC 170 determining 
the appropriate call type selected for the return call, not the 
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type of the received call as illustrated in Fig. 3, and also 
described at Col. 7, lines 4-10 (see for example Col. 4, lines 7- 
14). The received call at the organization (i.e., at the IIC 
170) is only one type, a CALL_US request launched from the 
caller's PC 112 (Col. 6, lines 17-19), wherein the caller or the 
system may choose the call type of the return call ("...the CALL_US 
request is parsed to determine call type...the initiating CGI 
script assigns a predetermined call type value to the call field 
if a specific call type is selected by the caller, and a null 
value is assigned if the call type is not selected...if the 
listener 174 determines that the call type field is a null value, 
indicating no specific call type, the call type is set to a 
default text - chat call type." Col. 7, lines 7-13). 

The Office Action cites Col. 1, lines 48-59, Col. 4, lines 
51-63, and Col. 8, lines 37-42 as disclosing selecting an agent 
of the plurality of agents based on type of call. Col. 1, lines 
48-59 merely describes determining a Call Center, not on agent 
not based upon call type. Col. 4, lines 51-63 merely describes 
the ITC determining a call center and agent best suited for the 
call but there is not disclosure of being based on call type. 
Col. 8, lines 37-42 merely describes routing to a specific agent 
if that agent has a special ability but does not mention basing 
the selection of the agent on determination of call type. Thus, 
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Lu does not disclose determining received call type or selecting 
an agent based upon received call type. 

Further, as the Office Action concedes Lu does not disclose 
independently spawning a call processing application based upon 
the determined call type and upon the selected agent coupled to a 
protocol stack at each end. The Office Action asserts, however, 
that Battin does disclose the independently spawning of the dual 
protocol coupled call processing application citing Figs. 5 and 6 
and protocol stacks 500 and 600. However, while Battin discloses 
a communications system which distributes the functions of a 
socket abstraction layer between the socket abstraction layers of 
a mobile subscriber and an agent communications device, it 
doesn't disclose independently spawning a call processing 
application based upon call type with a first end of the call 
processing application operatively coupled to a predetermined 
protocol stack of the selected agent and with a second end of the 
call processing application operatively coupled to a protocol 
stack of the client. Battin in Fig. 6 merely shows a protocol 
stack 600 of an agent communication device and Fig. 5 shows a 
protocol stack 500 of a client communications device each 
implemented in the processor of the respective device (Col. 9, 
lines 35-43) . There is no disclosure of independently spawning a 
call processing application based upon the determined call type, 
nor is there coupling of the first end of the spawned application 
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to the agent protocol stack and a second end to the client 
protocol stack. Thus, Battin does not disclose independently- 
spawning a call processing application based upon call type and 
the selected agent, or a call processing application having a 
first end operatively coupled to a predetermined protocol stack 
of the selected agent and a second and operating coupled to the 
protocol stack of the client. 

Further Battin fails to disclose communications between the 
agent protocol stack and the client protocol stack operates under 
a first protocol, and between the client protocol stack and the 
client through the public network under a second protocol. The 
cited abstract of Battin merely describes distributing functions 
of the socket layer and reducing the required headers. Col. 4-5, 
lines 26-11, merely describes establishing connections with a 
reduced-size header, and Col. 13, lines 9-31, merely describes a 
data communications system 900 with a wireless data terminal 902 
communicating with a data terminal 916 via a fixed infrastructure 
914. However, there is no description of communications between 
an agent protocol stack and a client protocol stack under a first 
protocol, and between the client protocol stack and the client 
through the public network under a second protocol. 

Because these features are not disclosed by any of the cited 
references, claims 1-40 are distinguishable over any combination 
of the cited references. 
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Further, the Office Action states that, Battin and Lu do not 
disclose a protocol stack of the agent and protocol stack of the 
client being disposed inside the private computer network and 
wherein communication between the predetermined protocol stack of 
the agent and protocol stack of the client operates under a first 
protocol and communication between the protocol stack of the 
client and the client through the public communication network 
operates under a second protocol, but asserts that Barnes does 
disclose this feature. Barnes concerns interfacing multiple 
protocol stack via a VCCT subsystem. There is no motivation or 
suggestion to combine Barnes' subsystem connected protocol stacks 
with Battin. Even if combined, there is no teaching or 
suggestion of an agent stack and a client stack structure coupled 
to each end of the spawned application as claimed. 

In addition, in Barnes, protocol messages generated by the 
first protocol stack 211 are sent to the second protocol stack 
221 via the VCCT subsystem 270 (Col. 4, lines 50-53) and are 
internally interconnected via the VCCT subsystem (Col. 12, lines 
2 6-28) . Thus, Barnes protocol stacks are physically connected by 
a VCCT subsystem not coupled by an independently spawned 
application operatively coupled to a protocol stack of the agent 
and to the protocol stack of the client. 

The Office Action also concedes that neither Lu, Battin, nor 
Barnes disclose the claimed continuously scanning idle input 
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stack locations of a protocol stack but asserts that this feature 
is disclosed by Childress. Childress concerns a mobile radio 
scanner and the cited portions (Col 8, lines 16-33 and Col. 9, 
lines 22-33, Col. 18, lines 29-44 and Col. 20, lines, 51-65) 
merely describe a radio scanner which scans the repeater 
transceiver frequencies to determine if there is a radio signal 
that exceeds a threshold radio signal strength. Childress does 
not, however, describe in any way the claimed scanning and 
reading of idle input stack locations of the client protocol 
stacks. For example, there are no protocol stacks, or idle stack 
locations being scanned. Nor is there any teaching, suggestion 
or motivation to combine this radio scanner with the entirely 
different systems of Lu, Battin or Barnes. Such a radio scanning 
system would be of no use with the systems of the other cited 
references or the claimed system. Thus, Childress does not 
disclose the claimed features and is not properly combinable. 
Accordingly the claims 1-4 0 are believed to be further 
distinguishable for these reasons as well. 

Since the combination of Lu, Battin, Barnes and Childress 
al . fails to provide any teaching of independently spawning a 
call processing application or basing such spawning on the call 
type and selected agent, continuously scanning idle input stack 
locations, or an independently spawned application operatively 
coupled to the protocol stack of the agent and to the protocol 
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stack of the client, the combination fails to teach or suggest 
each and every claim limitation. Because the combination fails 
to teach or suggest each and every claim limitation, the claims 
are distinguishable over the combination of cited references. 
Accordingly, claims 1-40 are believed to be distinguishable over 
the cited references. In addition, claim 10 now calls for 
spawning an application compatible with the determined format 
(see e.g., para. 51), and claim 12 has been amended to call for 
increasing or decreasing the number of stack locations based upon 
load. These features are believed to be further distinguishable 
over the cited art. 

The allowance of claims 1-40 as now presented, is believed 
to be in order and such action is earnestly solicited. Should 
the Examiner be of the opinion that a telephone conference would 
expedite prosecution of the subject application, he is 
respectfully requested to telephone applicant's undersigned 
attorney. 



November 2, 2 007 

WELSH & KATZ, LTD. 

120 South Riverside Plaza 

22nd Floor 

Chicago, Illinois 60606 
(312) 655-1500 



Respectfully submitted, 




/Dames A. Scheer 
Registration No. 29,434 
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